00100	A MODIFIABLE TIME-SHARING SYSTEM
00200	
00300	
00400		These thoughts are inspired by Andy Moorer's statement that
00500	it will take 100 hours of system down time to debug the IMP interface
00600	software and that it took 300 hours to debug the data disk code.
00700	
00800		By way of information, the complexity in the IMP code comes
00900	from the fact that it allows a number of jobs in our system to 
01000	communicate simultaneously with jobs in several other systems.
01100	
01200		It seems likely that the amount of system down time in this
01300	case could have been reduced by having a pseudo user program
01400	that communicates with the outside world and sorts out the messages
01500	to and from the different users within our own system and communicates
01600	with them by an internal communication mechanism.
01700	
01800		However, all this raises the general question of how to make
01900	a time sharing system that can be improved as much as possible while
02000	the system is running.  Here are some ideas:
02100	
02200		1. The modularity and the hierarchical structure of Multics
02300	and the IBM TSS undoubtedly contribute something towards this, but
02400	in fact these systems took an extraordinary length of time before 
02500	they were usable at all, and my impression is that improvements
02600	still require lots of system down time.  It would be interesting
02700	to know what TENEX offers in this direction.
02800	
02900		2. Putting as much of the system as possible into phantom
03000	users like the SPOOL and ACT, and LOGIN, LOGOUT, and the error
03100	phantom in THOR and ZEUS helps, but it is not the whole story.
03200	In particular, service programs for new i-o devices can't be
03300	handled this way.
03400	
03500		3. Well, maybe they can!  Suppose the actual i-o instructions
03600	are handled at least temporarily by UUO's, the program being debugged
03700	is locked into core, e.g. by spacewar mode, and its communication
03800	with user programs is also handled by UUO's.  This is not as good 
03900	as having a machine in which parts of the system can be restricted
04000	to certain i-o devices and to certain areas of memory.  The system
04100	would also have to be able to subject parts of the system to 
04200	clock interrupts and it would have to know how to go on if
04300	such a part of the system tried something illegal.  
04400	
04500		4. Would it be possible to debug a scheduler or a swapper
04600	with users on the system?  This seems a bit far out, but perhaps
04700	the system could go to a standard way of doing things when the 
04800	new way got confused.
04900	
05000		5. Even further out might be debugging a file system.
05100	
05200		6. In the long run a simulation of the system within
05300	the system is required.